Forum des exercices du projet Zuul

Exercice 7.49

  
 
Avatar Denis BUREAU
Exercice 7.49
par Denis BUREAU, mardi 19 novembre 2013, 15:39
 

Add moving characters. These are like other characters, but every time the player types a command, these characters may move into an adjoining room.

Utiliser l'héritage à bon escient ...

Avatar Hassan DIAB
Re: Exercice 7.49
par Hassan DIAB, mercredi 1 janvier 2014, 23:12
 

Bonsoir,

je ne vois pas quelle attribut en plus pourrait avoir un Movincharacter si il herite de Character, j'ai pensé à un attribut de type ROOM mais je ne sais pas comment la manipuler dans MovingCharacter.

merci d'avance

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, vendredi 3 janvier 2014, 19:37
 

Il n'y a pas de réponse unique à cette question ; cela dépend fortement de ce que vous prévoyez comme stratégie(s) de déplacement de vos MovingCharacter.

On peut imaginer une CurrentRoom, ou une liste de Room, ou un compteur pour "tourner" entre plusieurs Room, ou un générateur aléatoire de directions, ou un Item qu'il faut lui donner pour qu'il se déplace, ou tout ce que votre imagination vous suggérera ...

Il est aussi possible de se contenter d'ajouter une méthode de déplacement rudimentaire.

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, samedi 19 avril 2014, 14:26
 

Un étudiant a écrit :

Bonjour,

[...]

L'implémentation actuelle fait se déplacer le personnage dans une pièce
adjacente choisie aléatoirement. Cependant, il risque d'entrer dans une
TransporterRoom et ainsi de se retrouver n'importe où.
Pouvons-nous, à la place de choisir une pièce adjacente aléatoirement, définir un chemin que le MovingCharacter suivra ?
Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, samedi 19 avril 2014, 14:28
 

Oui l'essentiel dans cet exercice est de créer une classe de personnages qui changent de pièce.

Un tel personnage peut soit bouger dans une pièce adjacente, soit suivre le joueur, soit suivre un chemin pré-déterminé, ou toute autre philosophie de déplacement.

Avatar Jonathan MORELL
Re: Exercice 7.49
par Jonathan MORELL, jeudi 29 mai 2014, 23:34
 

Bonjour, si notre Class Character possède déjà l'attribut aCharacterCurrentRoom, il nous suffit de rajouter une méthode qui le permet de le faire bouger de room, est-ce bien ça ?

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, vendredi 30 mai 2014, 11:48
 

Oui, mais il faut s'assurer que le GameEngine demande aux MovingCharacters de se déplacer ...

Petite remarque : pourquoi ne pas avoir conservé le nom aCurrentRoom ?

Avatar Jonathan MORELL
Re: Exercice 7.49
par Jonathan MORELL, vendredi 30 mai 2014, 13:00
 

Juste pour obtenir une meilleur visibilité. Je préfere avoir des variables assez explicite même si je sais que j'aurai pu garder aCurrentRoom.

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, vendredi 30 mai 2014, 13:51
 

Je comprends, mais cela nuit à la généralisation, et vous empêcherait par exemple de mettre en commun cet attribut dans une classe dont hériteraient Player et Character ...

Avatar Jonathan MORELL
Re: Exercice 7.49
par Jonathan MORELL, mercredi 4 juin 2014, 00:53
 

Peut-ont au lieu de définir une nouvelle classe MovingCharacter crée la méthode public void move() dans Character avec un corps vide et donc redéfinir cette méthode seulement pour nos personnage qui doit bouger ?

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, mercredi 4 juin 2014, 09:52
 

Redéfinir move, mais où ???

--> dans MovingCharacter !

Avatar Jeremy CARADEC
Re: Exercice 7.49
par Jeremy CARADEC, lundi 4 mai 2015, 14:51
 

Bonjour monsieur,

J'aimerai que vous m'orientez sur la manière d'écrire proprement cette classe et ses sous classes.

Je me demandait si il était judicieux de rendre la classe NPC abstraite, et de créer une sous classe pour chaque type de NPC possibles (et la casse DefaultNPC pour un NPC qui n'a pas de caractéristique spéciale). Cette classe abstraite servirait aussi a implémenter la fonction abstraite setFeatures() qui initialisera les booléens informant sur les caractéristiques d'un personnage, cette fonction sera appelée dans le constructeur de NPC. Voici mon code pour clarifier les choses:

public abstract NPC{

public boolean aIsMoving;

public NPC (...){

..

aIsMoving = false;

setFeatures(); // si l'on est dans la classe MovingNPC, cette procédure rendra aIsMoving true

}

public void setFeatures();

/*

setter / getter des booléens

*/

}

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, mardi 5 mai 2015, 16:31
 

Une classe (abstraite ou non) NPC et des sous-classes : oui.
La "bidouille" avec des booléens : moins.

Essayez de mieux utiliser l'héritage en mettant en commun (dans la classe mère) tout ce qui peut l'être et en redéfinissant (dans des classes filles) ce qui doit l'être.

Mais chaque cas est particulier, selon la complexité (dialogues, inventaires, déplacements, ...) de vos personnages.

Avatar Jeremy CARADEC
Re: Exercice 7.49
par Jeremy CARADEC, mardi 5 mai 2015, 20:32
 

Très bien, mais du coup si chaque item n'a pas de booléen qui indique ce qu'il est, comment faire faire pour différencier les sous-classes dans les commandes ? Par exemple ma commande Charge ne peut fonctionner qu'avec un Beamer, hors je ne peux pas d'office convertir l'objet demandé en second mot en Beamer sans connaître sa classe. Il me faut donc un test pour déterminer la nature de l'Item, voilà pourquoi j'utilisais ces booléens. 

Avant les booléens, j'utilisait ce code:

String vClassString=""+pPlayer.getItemList().getItem(getSecondWord()).getClass();

        switch(vClassString){           

                case "class pkg_world.Beamer":  

                ... 

                } 

Mais, bien que ça fonctionne, ça ne me parait pas être une bonne solution non plus. 

Quelle serait donc la meilleure manière de différentier une classe et ses sous-classe dans les commandes ? 

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, mercredi 6 mai 2015, 15:41
 

Cette question sur les Item n'a plus de rapport avec cet exercice, mais la réflexion peut effectivement être commune, y compris à propos des Room :

Pourquoi n'avez-vous pas été obligé d'utiliser des booléens ou un switch pour utiliser la TransporterRoom ?  Comment celle-ci peut-elle avoir un comportement différent de celui d'une Room "normale" ?

Utilisez le même mécanisme pour le Beamer ...

Avatar Thibaut TRASSART
Re: Exercice 7.49
par Thibaut TRASSART, mardi 12 mai 2015, 20:36
 
J'aimerai faire en sorte qu'un Character se déplace de manière aléatoire. Mais peut-on limiter les Room où le Character peut se trouver ? 
Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, mardi 12 mai 2015, 23:26
 

Oui, bien sûr.
(voir aussi mes réponses des 3 janvier et 19 avril 2014 ci-dessus)

Avatar Thibaut TRASSART
Re: Exercice 7.49
par Thibaut TRASSART, jeudi 14 mai 2015, 18:57
 
Je rencontre une petite difficulté : pour pouvoir obtenir une Room aléatoire parmi une liste de Room (pour pouvoir déplacer mon MovingCharacter), j'ai pensé à réutiliser la classe RoomRandomizer (créée pour les TransporterRoom). Sauf que je rencontre un problème : ma classe RoomRandomizer possède des attributs statics. Ce qui fait que je ne peux pas utiliser cette classe pour ma TransporterRoom ET pour les MovingCharacter. 


Pour y remédié, j'ai créé une classe RoomRandomizerForMovingChracter qui reprend exactement la même structure que RoomRandomizer. Je trouve que cela fait un peu trop "bidouillage" mais je ne vois pas comment me contenter d'une seule classe RoomRandomizer...

Avatar Denis BUREAU
Re: Exercice 7.49
par Denis BUREAU, jeudi 14 mai 2015, 20:44
 

Pour moi, la question est : pourquoi y a-t-il des attributs statiques dans RoomRandomizer

Si vous parvenez à les remplacer par des attributs d'instance, vous aurez résolu votre problème.

Avatar Damien LEROUX
Re: Exercice 7.49
par Damien LEROUX, vendredi 1 mai 2020, 19:44
 

Bonjour,

J'aimerais savoir si le déplacement peut simplement correspondre à un appel effectué par le joueur, ou si le MovingCharacter doit pouvoir se déplacer tout seul ?

Merci.